Navigation route scheduler

ABSTRACT

Various embodiments relate to scheduling a future navigation route. A user may select one or more points of interests (POIs) along a route to be routed to in the future. The one or more POIs may be within a geographic vicinity of the vehicle in which the user is travelling when the user makes the selection. The user may also input a future date and/or time for routing to the selected POI. The user selected POI and the date and/or time may comprise routing event information, which may be stored in memory for future routing.

TECHNICAL FIELD

Various embodiments relate to scheduling a navigation route on a mobiledevice. In particular embodiments, the scheduled navigation route is fora specific time in the future. In some embodiments, the futurenavigation route may be to a point of interested identified on apresently traveled route.

BACKGROUND

Various examples exist in the art of trip planning systems. As oneexample, US Publication No. 2010/0312464 discloses an advice enginedelivering personalized search results and customized roadtrip plans.

As another example, US Publication Number 2003/0191578 discloses amethod and system for providing reminders about points of interest whiledriving. A user may specify a type of point of interest (or businesschain) and then receive a reminder when the user is in proximity to alocation of the point of interest of the specified type (or businesschain) while traveling in a geographic region.

As another example, U.S. Pat. No. 7,941,753 discloses communicatingappointment and/or mapping information among a calendar application anda navigation application. In particular, directions are provided to anappointment location appearing in a calendar application by identifyingan appointment in a calendar application, determining a geographiclocation of the appointment, identifying another geographic locationassociated with a user of the calendar application, generatingdirections between the geographic location of the appointment and thegeographic location of the other location, and providing the directionsgenerated to the user.

SUMMARY

One aspect includes a system for scheduling a navigation route. Thesystem may include a computing system for a vehicle. The computingsystem may be configured to receive a user's request to store one ormore points of interests (POIs) along a route for future routing. Theone or more POIs may be within a geographic vicinity of the vehicle. Theuser may select one or more POIs to store for a future routing event. Acorresponding location of the one or more selected POIs may be storedwith the POI. A future date and/or time for routing to the selected POImay be received. The POI and date/time information may comprise routingevent information. The routing event information may be stored for afuture routing event. In some embodiments, a playlist may be associatedwith the future routing event.

In some embodiments, reminders may be output regarding the futurerouting event. The reminders may be output to a nomadic device and/or apersonal computer.

The system may include one or more vehicle input controls for inputtingthe routing event information. The input controls may include, but arenot limited to, a vehicle touchscreen display, one or more vehiclebuttons, or one or more vehicle microphones.

Another aspect includes a computer-program product for scheduling afuture navigation event. The computer-program product may includeinstructions for storing routing event information for a future routingevent based on input at a first user device. The routing eventinformation may include an identification of one or more points ofinterest (POIs) within a geographic vicinity of the first user device, acorresponding location of the one or more POs, and a future date and/ortime for routing to the one or more POIs. Additional instructions may befor transmitting one or more reminders for the future routing event tothe first user device until the future routing event. Additionally oralternatively, the reminders may be transmitted to one or more seconduser devices until the future routing event. On the date and/or time ofthe future routing event as determined from the routing eventinformation and based on user instructions, a determination may be madewhether or not routing instructions to route to the one or more POIs canbe received by the first user device. The routing instructions may thenbe transmitted to the first user device if the routing instructions canbe received by the first user device. The routing instructions may betransmitted to the one or more second user devices if the routinginstructions cannot be received by the first user device. The first userdevice, which may be a vehicle head unit, may be remote from the one ormore second user devices, which may be a personal computer or a nomadicdevice.

In some embodiments, the one or more POIs may be displayed on a userdevice based on gestures associated with displaying one or more POIs.The one or more POIs may be selected from a navigation map displayed onthe first user device.

Another aspect includes a system for scheduling a future navigationroute. The system may include a processor for a user device. Theprocessor may be configured to receive a user's request to store one ormore points of interests (POIs) along a route for future routing. Theone or more POIs may be within a geographic vicinity of the user device.A user may select the one or more POIs to store for a future routingevent. The corresponding location of the one or more selected POIs maybe also stored. A future date and/or time for routing to the selectedPOI may be determined. The user selected POI and the date and/or timemay comprise routing event information. The routing event informationmay be stored for the future routing event. The system may also includeinput controls communicating with the user device for inputting therouting event information memory for storing the routing eventinformation.

BRIEF DESCRIPTION OF THE DRAWINGS

The figures identified below are illustrative of some embodiments of theinvention. The figures are not intended to be limiting of the inventionrecited in the appended claims. The embodiments, both as to theirorganization and manner of operation, together with further object andadvantages thereof, may best be understood with reference to thefollowing description, taken in connection with the accompanyingdrawings, in which:

FIG. 1 is an exemplary illustration of a vehicle computer system (VCS);

FIG. 2 is a system architecture of a system for scheduling a futurenavigation route;

FIG. 3 is a process for scheduling a future navigation route to adestination using a mobile navigation system;

FIG. 4 is an additional process according to one embodiment forscheduling a future navigation route to a destination using a mobilenavigation system;

FIG. 5 is an exemplary illustration of a process for scheduling a futurerouting to a destination while travelling in a vehicle; and

FIG. 6 is a process for initiating the scheduled navigation route androuting to the destination.

DETAILED DESCRIPTION

Detailed embodiments of the present invention are disclosed herein;however, it is to be understood that the disclosed embodiments aremerely exemplary of the invention that may be embodied in various andalternative forms. The figures are not necessarily to scale; somefeatures may be exaggerated or minimized to show details of particularcomponents. Therefore, specific structural and functional detailsdisclosed herein are not to be interpreted as limiting, but merely as arepresentative basis for teaching one skilled in the art to variouslyemploy the present invention. Additionally, the disclosure andarrangement of the figures is non-limiting. Accordingly, the disclosureand arrangement of the figures may be modified or re-arranged to bestfit a particular implementation of the various embodiments of theinvention.

It is not uncommon for someone to find a point of interest along aphysical route, particularly if the person is a visitor or resident in anew state, city or town and unfamiliar with the routes, which he or shemay want to visit in the future. However, it may be inconvenient to notedown the address or difficult to identify a portion of the address (suchas the building number or street name). Even if one is in his or herhome town, one may want to visit a particular place along the route at alater point in time (e.g., later in the day or the week). However,because the visit was not originally planned or is not part of theresident's routine, the resident may need a reminder to visit the pointof interest. For convenience, or if the user is unfamiliar with theroute to the point of interest from the point of origin, a calculatedrouted to the point of interest would also be helpful. By way of exampleonly, while travelling on a route through a city, a user may see that anevent, such as a fair, will taking place in one month. The user mayidentify a cross street or an address where, or near to where, the fairis to take place on the navigation map and set a route to the fair on aspecific date during when the fair is taking place. As another example,the user may want to navigate to the opening of a specific store whichis to occur in two weeks. As another example, while driving in a town 30minutes away from the user's home in the month of March, the user maywant to navigate to a restaurant during a restaurant fair in that town,known in some jurisdiction in the United States as “Restaurant Week,”which is to occur during a specific week in July.

In one or more embodiments of the disclosure, one or more users mayschedule a future routing to one or more destinations while concurrentlytravelling along a route. The scheduling may be accomplished using amobile device such as a mobile phone or a vehicle computing system.Through audible commands or a few tactile commands, the user may createa scheduled navigation route to a point of interest while travellingwithout much difficulty or hassle. One or more users may receivereminders about the future routing, which may be generated regardless ofthe vehicle's proximity to the point of interest for future routing.

FIG. 1 is a block diagram of a vehicle computing system (VCS) 102.Within a vehicle, a head unit 104 may have an onboard computing unit 106comprised of one or more processors (not shown) that provide foron-board processing of instructions and controls received by the VCS100. In some embodiments, the computing unit 106 may be a system on chip(SoC) construction, a system in package (SiP) construction, or a packageon package construction. Non-limiting examples of SoC include OMAP,SNAPDRAGON, and i.MX.

Data that may be received and processed by the onboard computing unit106 may be stored in memory 108. The memory 108 may includenon-persistent or volatile memory, such as (and without limitation)random access memory (RAM), and persistent or non-volatile memory, suchas (and without limitation) a hard disk drive (HDD) or flash memory.

The head unit 104 may also include a visual front end interface, such asa display 110, located in the vehicle. The display 110 may be an LCDdisplay or a graphical display. In some embodiments, the interface mayhave a touch sensitive screen. In additional or alternative embodiments,the interaction with the VCS 102 may occur through, button presses,audible speech and/or speech synthesis and displayed on display 110.

The VCS 102 is also provided with a number of different modules throughwhich the user can interact with the VCS 102. For example, the vehiclemay be provided with a microphone 112, one or more media components 114(e.g., and without limitation, one or more media inputs, such as, andwithout limitation, an auxiliary input or USB input for connecteddevices, a radio, a CD/DVD player, satellite radio, and the like), a GPSmodule 116, and a BLUETOOTH module 118. Additional media components mayinclude one or more rear entertainment devices 152. The rearentertainment device 152 may include one or more media players (e.g., aDVD player) and one or more displays visible to rear seat passengersfrom which video, picture and/or audio may be output.

The computing unit 106 may be in communication with a vehicle network(not shown) that communicates data to and from the various modules.Non-limiting examples of a vehicle network include an SAE J1850 bus, aCAN bus, a GMLAN bus, and any other like vehicle data buses. The vehiclenetwork may additionally or alternatively be a network for use withinfotainment systems such as a media oriented system transport (MOST),Ethernet, or an Audio-Video Bridge (AVB) network.

Additional modules of the VCS 102 may include one or more vehiclecameras 126. The vehicle cameras 126 may be front or rear view camerasand/or in the vehicle. For purposes of simplicity, a single camera 126is shown at the front of the vehicle. The output of the camera(s) 126may be presented on the display 110. One or more input controls 120 mayalso be provided to allow a user to swap between and activate variousmodules.

Signals passing from the microphone 112 may pass through one or moreanalog-to-digital converters 122 before being passed to the processor106 and vice-versa. Additionally, signals to and from some mediacomponents 114 (e.g., AM/FM radio) may also pass through one or more A/Dconverters 122 before being passed to or from the onboard computing unit106. For purposes of simplicity, one A/D converter 122 is shown.However, multiple A/D converters 122 may be arranged in the system 100.

The output from one or more vehicle modules of the VCS 102 may beaudible and/or visual output. Audible output may be output from one ormore in-vehicle speakers 128. The speaker(s) 128 may be connected to anamplifier 130 and may receive its signal from the processor 106. In somecases, the signals may pass through a digital-to-analog (D/A) converter(not shown). Visual outputs may be output on the display 110 and/or onone or more rear entertainment devices 152.

The vehicle may include an on-board modem 132 for two-way communicationof data and messages between the vehicle and an external network 134. Asa non-limiting example, modem 132 may be a USB cellular modem. As analternative example, the modem may be an embedded modem in the vehicle.The data and messages may be exchanged by communicating with the one ormore cellular towers 136.

Alternatively, via a BLUETOOTH transceiver 118 in the vehicle, acommunication or pairing may be made automatically with a user'sportable (sometimes referred to as “nomadic”) device 138 (e.g., mobilephone, smart phone, PDA, or any other device having wireless remotenetwork connectivity) after a vehicle key-on. In some embodiments,pairing the portable device 138 and the BLUETOOTH transceiver 118 may beinstructed through one or more buttons or similar input (not shown). Theone or more buttons may be one or more hard keys located in the vicinityof the vehicle driver (e.g., and without limitation, on the steeringwheel, in the center console, or near the display 110) and/or one ormore soft keys shown on the display 110. The soft keys may or may not betouch-sensitive (e.g., on a touchscreen display). Additionally oralternatively, the soft keys may be one or more physical buttons mappedto the one or more soft keys.

In yet an alternative embodiment, connectivity may be accomplished usinga USB connection linking the nomadic device 138 with the head unit 104via a USB module. In some embodiments, this connection may only beenabled using an accessory protocol. Non-limiting examples of accessoryprotocols include the IPHONE accessory protocol or the ANDROID accessoryprotocol.

Using the portable device 138, communication with an external network134 may be accomplished through, for example, communication with acellular tower 136 and/or a wireless access point 140. Data may becommunicated from the vehicle (e.g., from the onboard computing unit106) to the network 134 utilizing, for example, a data-plan, data overvoice, or DTMF tones associated with nomadic device 54.

Additionally or alternatively, the vehicle may be outfitted with one ormore wireless modules 142 for wireless communication with the network134. A non-limiting example of such a wireless communication is anycommunication system meeting the 802.11 IEEE standard such as WiFi orWiMax. To communicate with the network 134, a connection may be made toa wireless hotspot 140 (or wireless access point) which may be outsideand remote from the vehicle (e.g., and without limitation, at apublically available hotspot venue). In some embodiments, a wirelesshotspot may be created in the vehicle and communication with the network134 may be accomplished by wirelessly connecting one or more compatibledevices in the vehicle with the in-vehicle wireless access point. Forpurposes of simplicity and clarity, FIG. 1 shows an external hotspot140.

The computing unit 106 may be provided with an operating systemincluding an API to communicate with modem application software. Themodem application software may access an embedded module or firmware onthe BLUETOOTH transceiver 118 to complete wireless communication with aremote BLUETOOTH transceiver (such as that found in a nomadic device).

The nomadic device 138 may be capable of voice band and/or broadbanddata communication. A user may be able to transfer data over the voiceband using a technique called frequency division multiplexing. Thus, auser of the nomadic device 138 may be able to talk over the device whiledata is being transferred. If the user has a dataplan associated withthe nomadic device 138, broadband transmission may be possible.

Incoming data to the VCS 102 may be passed through the nomadic device138 via a data-over-voice or data plan through the onboard BLUETOOTHtransceiver 118 and into the vehicle's computing unit 106.Alternatively, the data may be passed through the embedded modem 132 viacellular communication to the computing unit 106. In some embodiments,data communication with the VCS 102 may be via server push messages assupported by the embedded modem. Alternatively, the data may be passedthrough the wireless module 142 via, e.g., a WiFi connection, to thecomputing unit 106. Data may be stored in the memory 108 of the VCS 102.

A navigation module 146 may be executing on the head unit 104 forcalculating and displaying navigation routes on display 110.Additionally, a navigation database 150 storing route information andmap data may also be stored and executing on the head unit 104. In someembodiments, the navigation database 150 may be executing remotely on aremote system (not shown) and communicating with head unit 104 vianetwork 134. Additional sources that may interface with the VCS 102 mayinclude personal navigation devices and/or onboard GPS devices.

Additionally communicating with the VCS 102 may be a variety of otherauxiliary devices connected through a wireless or wired connection.Auxiliary devices may include, but are not limited to, personal mediaplayers, wireless health devices, portable computers, and the like.

Additionally communicating with the computing unit 106 may be one ormore sensors 144. Sensors 144 may comprise interior and/or exteriorsensors. Interior sensors may include, but are not limited to, brakesensors and one or more internal cameras. A non-limiting example of anexterior sensor may include proximity sensors for detecting objects nearthe vehicle.

In some embodiments, one or more modules 148 for vehicle-to-vehicle(V2V) or vehicle-to-infrastructure (V2I) communication may alsocommunicate with the computing unit 106. The module 148 may be fordedicated short range communications (DSRC), wireless access invehicular environment (WAVE), WiFi, or other like wireless communicationenabling V2V or V2I communication. The module(s) 148 may be transceiversthat enable two-way short to medium range (e.g., up to 1000 meters)wireless communication capabilities. Typically, the dedicated shortrange communication works on a 5.9 GHz band with bandwidth of 75 MHz. Inaddition to being on-board in a vehicle, enabling vehicle to vehicle(V2V) communication with other capable vehicles, nodes may also beroadside units (RSUs) enabling vehicle to infrastructure (V2I)communication. V2V may be used to alert in two different vehicles aboutone vehicle approaching the other. The alerts may be a vehicle seatvibration, repeated brake light flashing, graphics shown on a display,and the like. The messages received during a V2V or V2I exchange aretypically transmitted within the vehicle over a vehicle network.

FIG. 2 shows the architecture for a system for scheduling and setting afuture route on a mobile device. In one embodiment, the mobile devicemay be the navigation system 146 of the VCS 102. In another embodiment,the mobile device may be a portable, handheld device such as a mobilephone, a personal media player, a portable navigation device, and thelike. For purposes of simplicity and brevity, the mobile device willherein be represented by navigation system 146.

A user may schedule a future routing to a destination from the mobiledevice 146 while travelling in a vehicle on a particular route. Thecurrently traveled route may or may not be calculated on the navigationsystem 146. As used herein, a current route is a route that the user iscurrently travelling and a future route is a route which the userschedules to travel at a later point in time. For example, a user maywant to visit a point of interest (POI), such as a POI that is new tothe user, which is along the currently traveled route at a later time.The user may use the touch screen display 110 to select the unvisitedPOI from a navigation map displaying the POI. Alternatively oradditionally, the user may use audible commands to select the POI.Further details of the POI selection and navigation route schedulingprocess will be described below.

The selected POI may be stored and associated with the location of thePOI (generally referred to herein as “POI information”). The locationinformation for the POI may be stored as latitude/longitude information,GPS coordinates, an address, or the like. The POI information may alsobe stored with date and/or time information (generally referred toherein as “routing event information”) to associate when in the futurethe navigation route should be generated. In some embodiments, acalendar application may be running on the VCS 102 and the routing eventinformation may be stored on the calendar as a calendar entry. A vehicleclock (not shown) may monitor the date and time for determining when totrigger the route calculation. Further details of triggering a routecalculation based on routing event information are described below withrespect to FIG. 5.

The routing event information may be stored on one or more of a numberof devices. The information may be stored in memory 108 of the VCS 102.Alternatively, the routing event information may be stored on a mobilephone or other non-vehicle based portable device (not shown) if the userwants to store a future routing event outside of the vehicle. In theformer case, software for enabling the scheduling of a future navigationroute, and the various additional functions and features of the variousembodiments (described in further detail below), may be executing on thecomputing unit 106 of the VCS. In the latter embodiment, the softwaremay be executing on the mobile device.

The routing event information may additionally or alternatively beserved and stored remotely 206 using a server and database system forthe routing event information. The industry term for such remote serviceand storage is generally known as the “cloud” and system 206 will bereferred to as the “cloud” herein and throughout this disclosure.Communicating with the cloud system 206 via network 134, which may bethe Internet, may be a number of devices from which the user may performa number of actions with respect to the future navigation route.Non-limiting examples of such devices include a personal computer 200, anomadic device 138, and/or a home theater system 204. When the futurenavigation route (i.e., the routing event) is set from the VCS 102, theuser may store the routing event information in the cloud 206 as well.

From the personal computer 200 or the nomadic device 138, a user mayperform one or more actions including, but not limited to, retrievingthe scheduled routing event information, modifying the routing eventinformation, receiving reminders regarding the future navigation route,and/or add or modify playlists associated with the scheduled routingevent. A user may additionally or alternatively add and/or modifyplaylists associated with the scheduled routing event from the hometheater system 204. The home theater system 204 may include one or moreA/V receiver, one or more interface (e.g., a television) and one or morespeakers. Details of creating a playlist to associate with the scheduledrouting event will be described in further detail below.

Each of the devices may have a network connection 134 to the cloudsystem 206 and software running on the respective device through whichthe alerts regarding the routing event may be received or the routingevents may be modified. In some embodiments, the software may include anelectronic calendar. Alternatively, software may be executing on aserver in the cloud 206 and messages regarding the routing event may beexchanged between the devices and the cloud system 206. In someembodiments, the cloud software may include an electronic calendar. Eachof the devices 138, 200, 204 may be executing software for communicatingwith the cloud-based routing event service and for enabling one or moreuser actions described above relating to the routing event to beperformed from the devices. Each of the devices may also have agraphical user interface (GUI) through which the user may perform theseactions including, but not limited to, inputting and transmittingcommands and receiving return information from the cloud system 206. Allmodifications to the routing event information from the devices 138,200, and 204 that are transmitted to the cloud 206 may be updated at theVCS 102 simultaneously or near simultaneously if there is a persistentnetwork connection in the vehicle (e.g., and without limitation, througha WiFi hotspot). Alternatively or additionally, the updates may occurwhen the vehicle is keyed on. In some embodiments, at least some of themessages regarding the routing event may be transmitted directly betweenthe VCS 102 and the devices 138, 200, and 204 without passing throughthe cloud-based system 206. For purposes of clarity, the nomadic device138 and the mobile device described above are separate to explain thedifferent environments in which a user may use a mobile device (e.g., ina vehicle and outside of a vehicle). However, one of ordinary skill inthe art will understand that both may be the same device as well.

In some embodiments, a user may transfer the routing event informationto other users. The event information may be transmitted to remotedevice as described above and/or to other users' VCS using methods knownin the art.

In some embodiments, the route event information may be available in anynumber of a user's vehicles, even if the user purchases a new vehicle.For example, the user may transfer the information using a portablememory device. As another example, the user may obtain the routing eventinformation stored in the cloud based system 206.

FIG. 3 illustrates a process for scheduling the future navigation routewhile the user is travelling in the vehicle. The vehicle navigationsystem 146 is started at vehicle key on (block 300). A destination mayor may not be entered by the user and a route may or may not becalculated by the navigation system 146. As the vehicle is travellingalong a route (block 302), the vehicle's position is tracked based onGPS data and other methods known in the art (block 304). The location ofthe POIs along the traveled route based on the vehicle position areidentified and displayed on the navigation display 110 (block 306). Insome embodiments, the POIs along the route may be identified based onmap data stored in the navigation database 150 and using processes suchas geocoding and/or reverse geocoding. Other methods of identifying thePOIs may be used without departing from the scope of the invention.

While driving, the user, such as a driver or another passenger, in thevehicle may identify a POI on the physical route which the user may wantto visit at a later date or time (block 308). The date and/or time forthe future routing may be to route to a POI which was not previouslyknown by the user or was not intended as a destination by the userbefore the user began travelling in the vehicle and the user desires toroute to that destination on a specific day of the week and/or time ofday. The POI may be a different POI than the user's current destination.If the user is driving, it may be inconvenient for the user to note downthe address of the POI or it may be difficult to determine the address(e.g., the building or house number cannot be seen). As a non-limitingexample, the driver may be new to a particular city and, on the way to afriend's house in the suburbs, identifies a retail store along the routeto visit the next weekend. As will be described in further detail below,rather than the user having to guess the route to the retail store orfind the address of the retail store from home for entry into thenavigation system, the user can immediately select the retail store fromthe navigation map and store in memory as routing event information. Theuser may select directly from the map or, in some embodiments, be givena list of POIs in the surrounding area (e.g., based on a vicinity) andselect the POI from the list. The list may be displayed in response to arequest from the user. In some embodiments, as will also be describedbelow, the user may use audible commands to select the POI.

While on the route, one or more users may use tactile or audiblecommands to select the POI for future routing (block 310). The user mayalso provide a specific time and date for the routing event. The routingmay be scheduled while the user is in a vehicle or while the user isusing a mobile device outside of a vehicle such as, and withoutlimitation, while the user is walking or running. As used in the variousembodiments of the disclosure, a vehicle may be an automobile, bus,boat, 2-wheel or 4-wheel bikes, and the like. A tactile command mayinclude touching the specific POI on the display if, e.g., the displayis touch screen. In other embodiments, the user may use soft buttons toselect a POI. Soft buttons or keys may be mechanical buttons that areprogrammed to perform one or more functions. Soft buttons may belocated, without limitation, on or near the head unit or on a vehiclesteering wheel. Other input controls may include a joystick orcontroller located in the center stack of the vehicle. Audible commandsmay include spoken or verbal commands for displaying the POIs and/orscheduling the future navigation route. Further details of using tactileand audible commands will be described below with respect to FIG. 5.

The POIs along the route may be displayed on display 110 as icons on themap and/or may be shown as a menu or list of POIs that the user in thevehicle is passing or which are near to the vehicle. The menu or list ofPOIs may dynamically change as the user travels along the route andpasses POIs along the route. In some embodiments, the POIs may beordered based on distance from the vehicle. In additional or alternativeembodiments, the POIs may be arranged on the display 110 according tothe side of the road on which the POI is located as determined from thevehicle's direction of travel or according to the side of the vehiclethat the POI is located as determined from the vehicle's direction oftravel. The display 110 may also indicate the side of the road on whichthe POI is located. A non-limiting illustration of the layout of thedisplay 110 is shown in FIG. 5, which will be further described indetail below.

In some embodiments, one or more gestures may be used to trigger adisplay of the surrounding or nearby POIs (block 312) on the display110. For example, the user may hover over a portion of the navigationdisplay 146 using a finger or a hand. As a non-limiting example, theuser may hover over a side on the navigation display 110 whichcorresponds to the side on which the POI is located on the road. Asanother example, the user may hover anywhere on the display to show thePOIs near or within a certain distance range from the vehicle. When theuser stops hovering over the portion of the display 146, the POIsdisappear. In some embodiments, the POIs may be shown for a definedperiod of time while the user is hovering over the display for safetypurposes.

Upon selecting the POI, the POI information may be stored in memory(block 312). In some embodiments, the POI information may temporarilystored in memory or cached. If the user is using the navigation systemto route to the destination, temporarily storing the POI information maypermit the user to create the routing event information withoutinterrupting the concurrent routing to a destination.

The user may add date and/or time information for the future routing tothe POI to create a routing event (block 314). The routing event may bestored for later retrieval and routing based on the routing eventinformation (block 316). The user may create the routing event and storethe routing event information for future routing in a number of ways. Asone non-limiting example, a separate window may be displayed with aninterface to input a date and/or time for the future routing. Theinterface may include one or more of text fields, drop menus, and thelike. In some embodiments, the window may be a pop up window. In someembodiments, the date/time interface may be an electronic calendar. Inadditional or alternative embodiments, the calendar may be the user'spersonal calendar or tied to the user's personal calendar. In thisembodiment, the user may enable permissions and/or access by the routingsoftware to the user's personal calendar. As another non-limitingexample, a window may be displayed first asking the user whether toroute to the selected POI or to save for later routing. If the userelects to save the route, the user may be presented with the interfacefor entering the date and/or time. As yet another non-limiting example,the user may select an option to set a destination for future routing tothe POI from a menu of options. In alternative or additionalembodiments, any of the various system and user actions described abovemay be accomplished through audible commands and prompts (e.g., andwithout limitation, voice commands and prompts).

The user may store the routing event information (block 316) usingtactile and/or audible commands. The routing event information may bestored locally (e.g., in memory 108) and/or in the cloud 206. In someembodiments, the routing event information may be stored on the nomadicdevice 138 by transmitting the information from the VCS 102 to the phone138 using a wireless connection such, and without limitation, BLUETOOTH,WiFi, and the like.

If the routing event information is stored in the cloud 206, the usermay receive reminders of the future routing on any one or more ofnon-vehicle devices 138 or 200. The reminders may include all theinformation included in the routing event information. A user may alsoview and modify the routing event information from any one or more ofthe same devices.

In some embodiments, the user may associate additional information withthe routing event information as shown in FIG. 4 and described below. Asshown in block 400 and described above, the user inputs a future dateand/or time for the future routing to the selected POI (or multiplePOIs) (block 400). The user may associate an identifier with the routingevent information for ease of recognition of the POI, particularly sincea user can schedule the routing up to years in advance. Alternatively,the user may store the routing event information as the name of the POI,which in some cases may be the default identifier. If the user choosesto provide an identifier to the routing event information (block 402),the user may be prompted to input the identifier (block 404) and theuser my input and store the identifier with the routing eventinformation (block 406). If the user does not choose to input anidentifier, a default identifier may be used (block 402).

At times, the user may desire to associate specific media, such as a CD,a particular radio station, a playlist or the like, to the futurerouting event. During the route event setting process, the user may alsobe prompted as to whether to add media items to associate with thefuture route (block 408). Using the routing event scheduling software,the user may set the VCS 102 to automatically play a particular station,track, or playlist upon the navigation system 146 starting the scheduledrouting event. Alternatively or additionally, the user may set areminder as part of the routing event information to send a reminder theuser to bring certain media to the vehicle. As another example, the usermay save a playlist stored in the cloud and associate it with therouting event information. As another example, the user may associate acurrently playing track or playlist with the routing event information.When the routing event occurs, the associated media may automaticallyplay or the user may receive a visual or audible reminder in the vehicleto play the associated media. The user may alternatively or additionallybe asked to confirm whether to play the associated media.

The routing event information may be modified or deleted by the user atanytime. For example, the identifier and/or media items may be laterassociated with the routing event information rather than when creatingthe routing event. Further, any one of the POI, date, time, theidentifier, and/or media items may be modified at a later point in time.Further, if the routing event information is stored in the cloud, theuser may modify the routing event information from locations outside ofthe vehicle where an Internet connection is available. In someembodiments, the user may enable or disable certain features. As anon-limiting example, the user may disable routing to the one or morePOIs, but the media items are still played on the saved date and/ortime. As another non-limiting example, the opposite may be true as well(i.e., the media selection is disabled, but the routing is enabled).

If the user associates media items with the routing event information,the VCS 102 (via the software) associates a media item with the routingevent information (block 410). If the user does not add media items(block 408), the routing event information may be stored (block 412).Accordingly, the routing event information may be associated with one ormore of an identifier and media items.

FIG. 5 provides an illustration of the operation as described above withrespect to creating a routing event. While the vehicle is moving, anavigation map may be displayed on the navigation display 110 (500). Thenavigation system 146 may or may not have calculated a route. As theuser is travelling a route, one or more POIs which the user may want tovisit in the future may be identified by the user from the physicalroute. The user may either use tactile or audible commands to identifythe POI on the navigation display 110 and to store for future navigation(502). As one non-limiting example of a display layout, the display mayshow the navigation map on a first portion of the display 110 and thePOIs as text on a second portion of the display 110 when the usertouches a portion of the display 110 (e.g., and without limitation, thenavigation map). In some embodiments, upon touching the display 110, apop up window may be displayed (not shown) asking the user if storing afuture navigation route is desired. In some embodiments, the pop upwindow may be displayed when the user hovers over the display 110. Inadditional or alternative embodiments, the POIs in the surrounding areaof the vehicle may be automatically displayed when the user hovers overa portion of the display 110. Other non-limiting examples of displaylayouts are described above. If the user uses audible commands, thedisplay may or may not change as described above.

Upon selection of the POI, the user may be shown an interface forinputting a date and/or time for the future routing (504).Alternatively, the user may audibly input the date and/or time. The usermay input the date and/or time, which may be input audibly or visually(as shown in FIG. 5 for clarity) (506). Once input, the user may receivea confirmation of the future routing (508). By way of example shown inFIG. 5, and not limitation, the display may show the name of the POI oraddress along with the date and/or time of the future routing. Forpurposes of generality, a specific POI nor a specific date and/or timeare shown.

Once the routing event is created, a navigation route to the one or morePOIs may be calculated and the user routed to the destination(s). Whilethe future routing event may be scheduled for a date and/or time, theuser may also route to the destination(s) at any time before thescheduled routing. FIG. 6 illustrates the process for initiating therouting event based on whether the routing event is initiated by theuser or based on the scheduled routing.

After the navigation system is started (block 600), the user mayinitiate the route calculation to the one or more scheduled POIs or theroute may be calculated at the scheduled date and/or time (block 602).If user initiated, the user may select the one or more scheduled POIsfrom the stored POIs (block 604). As described above, the POIs may bestored locally and/or in the cloud 206. The user may identify thescheduled POIs from other POIs stored in the navigation system 146through an identifier (such as, and without limitation, a graphic, text,and/or the identifier defined by the user as described above). In someembodiments, the scheduled POIs may be retrieved using a separate menuoption from other POIs in the system 146. In some embodiments, the usermay select the scheduled POIs directly from the electronic calendar.

Upon selection of a scheduled POI by the user, the POI information maybe transmitted to a route calculation module of the navigation system146 for calculating the route. The route may be calculated and the userrouted to the POI at a different time and/or date than the scheduledrouting event (block 606).

The user may keep the scheduled route for later routing (block 608).Upon selection of a scheduled POI, the user may receive a visual oraudible request or confirmation to route to the scheduled POI at a laterdate and/or time. As a non-limiting example, the confirmation may bedisplayed as a pop-up window on the display 110. The confirmation mayalternatively be audibly output through a spoken prompt. If the route tothe POI is saved for later routing (block 608), the user may schedule anew date and/or time or keep the scheduled date and/or time (block 610).If not, the scheduled routing to the POI may be deleted or disabled atthe system 146 (block 612).

Referring back to block 602, the route event may be initiated accordingto the scheduled event. Since at least one purpose of scheduling afuture route is to automatically route the user to a destination on aspecified date and/or time, it may be determined whether the VCSnavigation system 146 is in an active state on the date and/or time ofthe routing event (block 614). If active, a reminder or confirmation maybe output from the VCS (e.g., visually or audibly) regarding thescheduled routing (block 616). The user may or may not navigate to thescheduled destination (block 618). In some embodiments, the user may setthe routing event to automatically generate the route to the destinationwithout a confirmation. If navigation to the scheduled destination isconfirmed, the location information may be transmitted to the routecalculating module of the navigation system 146 (block 620) and theroute generated (block 622).

If the user does not execute a route calculation to the scheduleddestination (block 518), a message or request prompt may be outputasking if the user wants to postpone routing to the scheduleddestination (block 624). The prompt may be output visually and/oraudibly. If not postponed, the routing event may be disabled orsuspended (block 626). On the other hand, if the routing is postpone(block 624), the user may reschedule the routing (block 628).

Referring to back to block 614, if the vehicle navigation is not active,it may be determined whether notification of the scheduled routing maybe sent to another device (block 630) such as those shown in FIG. 2 anddescribed throughout this disclosure. In some embodiments, a user maycreate a profile including the other devices with which the system maycommunicate. In other embodiments, the user may include the otherdevices as part of the routing event information. If no other devicesare found, the routing event may be suspended until the navigationsystem 146 is in an active state (block 632). Based on monitored dateand/or time information, it may be determined whether the scheduled dateand/or time has passed (block 634). If not, the state of the navigationsystem 146 will continue to be monitored until it is active (block 632).If the date and/or time has passed, the routing event may be disabled orsuspended (block 636).

If other devices are found (block 630), one or more of the remotedevices 138 or 200 may be identified (block 638). One or more messages(such as, and without limitation, the future routing reminder) may betransmitted to the one or more remote devices 138 or 200 (block 640).One or more reminder(s) may be output from the remote devices (block642).

In some embodiments, after receiving the reminder, the user may transmitthe POI location from the remote devices 138 or 200 to the navigationsystem 146 (block 644) for calculating the route. It may or may not berequired for the user to remotely start the vehicle (e.g., using aremote start transmitter) to activate the navigation system 146.

While exemplary embodiments are described above, it is not intended thatthese embodiments describe all possible forms of the invention. Rather,the words used in the specification are words of description rather thanlimitation, and it is understood that various changes may be madewithout departing from the spirit and scope of the invention.Additionally, the features of various implementing embodiments may becombined to form further embodiments of the invention.

What is claimed is:
 1. A system for scheduling a navigation route, thesystem comprising: a computing system for a vehicle configured to:receive input associated with a user request to store one or more pointsof interests (POIs) along a route for future routing, the one or morePOIs being within a geographic vicinity of the vehicle when the userrequest is input; receive a user selection of a first POI included inthe one or more POIs to store for a future routing event, wherein thefirst POI is associated with a corresponding location; receive in thevehicle a user selection of a future date and/or time for routing to thefirst POI, the first POI, and the corresponding location of the firstPOI defining the future routing event; store the future routing event;determine that the user does not execute a route calculation to thefirst POI at the future date and/or time; output a message or requestprompt asking whether the user wants to postpone routing to the firstPOI; and if routing to the first POI is not postponed, then cancel thefuture routing event, and if routing to the first POI is postponed, thenallow the user to reschedule the future routing event.
 2. The system ofclaim 1 wherein the computer system is further configured to output oneor more reminders regarding the future routing event.
 3. The system ofclaim 2 wherein the output is to one or more of a nomadic device or apersonal computer.
 4. The system of claim 1 wherein the computing systemis further configured to receive a playlist to associate with the futurerouting event.
 5. The system of claim 1 further comprising one or morevehicle input controls for inputting the routing event information. 6.The system of claim 5 wherein the one or vehicle input controls includeone or more of a vehicle touchscreen display, one or more vehiclebuttons, or one or more vehicle microphones.
 7. The system of claim 1further comprising memory remote from the vehicle for storing the futurerouting event.
 8. The system of claim 1 wherein the computing system isremote from the vehicle.
 9. A system for scheduling a future navigationroute, the system comprising: a memory storing instructions and a futurerouting event; a processor for a user device, wherein the processor iscoupled to the memory and, when executing the instructions, isconfigured to: receive input associated with a user request to store oneor more points of interests (POIs) along a route for future routing, theone or more POIs being within a geographic vicinity of the vehicle whenthe user request is input; receive a user selection of a first POIincluded in the one or more POIs to store for the future routing event,wherein the first POI is associated with a corresponding location;receive in the vehicle a user selection of a future date and/or time forrouting to the first POI, the first POI, and the corresponding locationof the first POI defining the future routing event; store the futurerouting event; determine that the user does not execute a routecalculation to the first POI at the future date and/or time; output amessage or request prompt asking whether the user wants to postponerouting to the first POI; and if routing to the first POI is notpostponed, then cancel the future routing event, and if routing to thefirst POI is postponed, then allow the user to reschedule the futurerouting event; and one or more input controls communicating with theuser device for inputting information related to the future routingevent.
 10. The system of claim 9 wherein the processor is furtherconfigured to transmit one or more reminders for the future routingevent to the user device until the future routing event.
 11. The systemof claim 1, wherein the computing system is further configured to:receive new routing event information to reschedule the future routingevent; and reschedule the future routing event based on the new routingevent information.
 12. The system of claim 1, further comprising anavigation display, wherein the computing system is further configuredto display the one or more POIs in response to the user hovering overthe navigation display.
 13. The system of claim 12, wherein the hoveringoccurs over a defined area of the navigation display.
 14. The system ofclaim 9, wherein the processor is further configured to: receive newrouting event information for rescheduling the future routing event; andreschedule the future routing event based on the new routing eventinformation.
 15. The system of claim 9, wherein the processor is furtherconfigured to: cancel the future routing event if new routing eventinformation is not received in response to the request to reschedule.16. The system of claim 9, wherein the processor is further configuredto: display the one or more POIs in response to the user hovering over adefined area of a navigation display.